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(54) Pre-paid links to networks servers 



(57) The author or sponsor of a document on a serv- 
er may provide a hyperlink to content that requires pay- 
ment to view or download. The author or sponsor can 
prepay for access to that content in a manner that is 
transparent to the end user. In one approach the au- 
thor's document is generated dynamically, when a user 
requests it. During the generation process a payment 



token is inserted into hyperlinks to payment-required 
content to which the author or sponsor desires to permit 
free access. When the user selects a pre-paid hyperlink 
the remote server attempts to validate the payment to- 
ken. If the token is valid then the content is provided to 
the end user and the author or sponsor is billed. If the 
token is not valid an error message is displayed. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] This invention relates to computer systems 
and more particularly to information retrieval systems 
operating over a network such as the Internet. 

Description of Related Art 

[0002] Owners of electronic content that can be ac- 
cessed via a computer network may charge a fee to view 
or download their content. For example, users may be 
required to pay for a subscription in order to access an 
online newspaper or magazine. Access to other types 
of content (i.e., software, music, and videos) may re- 
quire the user to pay a one time fee in order to view or 
download it. Many examples of subscription and one 
time payment-required content can be found on the 
World Wide Web. 

[0003] Payment for access to information may take 
any form, such as; credit cards, checks, electronic cash, 
and smart debit cards. Payments that require the trans- 
mission of data (e.g., credit cards, electronic cash, and 
smart debit cards) typically make use of an encryption 
technique. Many encryption techniques, such are pub- 
lic-private key cryptography, are known in the art. 

The Problems 

[0004] Sponsors of websites, or similar sources of in- 
formation on networks may want to provide users with 
hyperlinks to other online content, some of which may 
require a payment to view or download. For example, a 
World Wide Web page author or sponsor may want to 
provide a hyperlink to a newspaper article that reported 
favorably on his product. Therefore, to encourage users 
to visit a payment-required site, such an author or spon- 
sor would like, in some cases, to enable a visitor to his 
network server (hereinafter website) to access the pay- 
ment-required content for free. This capability has not 
been available in the prior art. 

SUMMARY OF THE INVENTION 

[0005] The invention provides methods, apparatus, 
systems, and computer program products which allow 
a document author or sponsor to provide a hyperlink, by 
which users can access content for free by prepaying 
for the access. When a user requests a document using 
a hyperlink to payment-required content, a payment to- 
ken and optional parameters are appended to the hy- 
perlink definition. A payment token is a string of data 
that may include details about the account to charge for 
the content and when access to the content should ex- 
pire. 



[0006] When a user selects a payment-required hy- 
perlink, the token and parameter information are trans- 
mitted to the destination server for processing. If the to- 
ken is valid then the payment-required content is trans- 

5 mitted to the user. 

[0007] The processes described above are transpar- 
ent to the user. The original document appears normal 
to the user and the user may not know that access has 
been granted to payment-required content. In an alter- 

10 native embodiment the user may be notified that free 
access has been granted to payment-required content 
courtesy of the original sponsor or author. 
[0008] The foregoing and other features, aspects and 
advantages of the present invention will become more 

*5 apparent from the following detailed description of the 
present invention when taken in conjunction with the ac- 
companying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 

[0009] The objects, features and advantages of the 
system of the present invention will be apparent from 
the following description in which: 
[0010] Figure 1 A is an illustration of a computer of a 

25 type suitable for carrying out the invention. 

[0011] Figure 1B is a block diagram of an exemplary 
bus architecture suitable for carrying out the invention. 
[0012] Figure 1C is an illustration of an exemplary 
memory medium for carrying program information and 

30 data for use in carrying out the invention. 

[001 3] Figure 1 D is a block diagram of an exemplary 
network suitable for carrying program and data informa- 
tion useful for carrying out the invention. 
[001 4] Figure 2 is a flow chart of an exemplary proc- 

35 ess for making payment-required content available to 
users for free in accordance with one embodiment of the 
invention. 

[001 5] Figure 3 is a flow chart of an exemplary source 
page generation process for generating a server docu- 
40 ment with pre-paid links in accordance with one embod- 
iment of the invention. 

[0016] Figure 4 is a flow chart of an exemplary pay- 
ment token generation algorithm in accordance with one 
embodiment of the invention. 
45 [0017] Figure 5 is a flow chart of an exemplary des- 
tination server process for handling requested pre-paid 
content. 

[0018] Figure 6 is a flow chart of one embodiment of 
a process for checking the validity of a pre-payment to- 

50 ken and issuing an appropriate response. 

[0019] Figure 7 is a flow chart of one embodiment of 
a process for honoring a valid pre-payment token. 
[0020] Figure 8 is a flow chart of one embodiment of 
a process for maintaining a server pre-payment token 

55 database. 

[0021] Figure 9 is an example of a hyperlink with a 
customer identifier parameter and a pre-payment token. 
[0022] Figure 10 is an example of a pre-payment to- 
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ken that includes the customer identifier, the token coun- 
ter value, and the token expiration date and time. 

NOTATIONS AND NOMENCLATURE 

[0023] The detailed descriptions which follow may be 
presented in terms of program procedures executed on 
a computer or network of computers. These procedural 
descriptions and representations are the means used 
by those skilled in the art to most effectively convey the 
substance of their work to others skilled in the art. 
[0024] A procedure is here, and generally, conceived 
to be a self-consistent sequence of steps leading to a 
desired result. These steps are those requiring physical 
manipulations of physical quantities. Usually, though not 
necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, trans- 
ferred, combined, compared, and otherwise manipulat- 
ed. It proves convenient at times, principally for reasons 
of common usage, to refer to these signals as bits, val- 
ues, elements, symbols, characters, terms, numbers, or 
the like. It should be noted, however, that all of these 
and similar terms are to be associated with the appro- 
priate physical quantities and are merely convenient la- 
bels applied to these quantities. 
[0025] Further, the manipulations performed are often 
referred to in terms, such as adding or comparing, which 
are commonly associated with mental operations per- 
formed by a human operator. No such capability of a 
human operator is necessary, or desirable in most cas- 
es, in any of the operations described herein which form 
part of the present invention; the operations are ma- 
chine operations. Useful machines for performing the 
operation of the present invention include general pur- 
pose digital computers or similar devices. 
[0026] The present invention also relates to appara- 
tus for performing these operations. This apparatus may 
be specially constructed for the required purpose or it 
may comprise a general purpose computer as selective- 
ly activated or reconfigured by a computer program 
stored in the computer. The procedures presented here- 
in are not inherently related to a particular computer or 
other apparatus. Various general purpose machines 
may be used with programs written in accordance with 
the teachings herein, or it may prove more convenient 
to construct more specialized apparatus to perform the 
required method steps. The required structure for a va- 
riety of these machines will appear from the description 
given. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0027] Figure 1 A illustrates a computer of a type suit- 
able for carrying out the invention. Viewed externally in 
Figure 1 A, a computer system has a central processing 
unit 100 having disk drives 11 OA and 11 0B. Disk drive 
indications 11 OA and 11 0B are merely symbolic of a 
number of disk drives which might be accommodated 



by the computer system. Typically, these would include 
a floppy disk drive such as 11 OA, a hard disk drive (not 
shown externally) and a CD ROM drive indicated by slot 
110B. The number and type of drives varies, typically, 
s with different computer configurations. The computer 
has the display 120 upon which information is displayed. 
A keyboard 130 and a mouse 140 are typically also 
available as input devices. Preferably, the computer il- 
lustrated in Figure 1 A is a SPARC workstation from Sun 
10 Microsystems, Inc. 

[0028] Figure 1 B illustrates a block diagram of the in- 
ternal hardware of the computer of Figure 1A. A bus 
150 serves as the main information highway intercon- 
necting the other components of the computer. CPU 155 
is is the central processing unit of the system, performing 
calculations and logic operations required to execute 
programs. Read on ly memory (1 60) and random access 
memory (165) constitute the main memory of the com- 
puter. Disk controller 170 interfaces one or more disk 
drives to the system bus 1 50. These disk drives may be 
floppy disk drives, such as 173, internal or external hard 
drives, such as 172, or CD ROM or DVD (Digital Video 
Disks) drives such as 171. A display interface 125 inter- 
faces a display 1 20 and permits information from the bus 
to be viewed on the display. Communications with ex- 
ternal devices can occur over communications port 1 75. 
[0029] Figure 1C illustrates an exemplary memory 
medium which can be used with drives such as 173 in 
Figure 1 B or 1 1 0A in Figure 1 A. Typical ly, memory me- 
dia such as a floppy disk, or a CD ROM, or a Digital 
Video Disk will contain the program information for con- 
trolling the computer to enable the computer to perform 
its functions in accordance with the invention. Program 
and data information from such media is transmitted, in 
accordance with the invention, over a transmission link 
in the form of a carrier wave. 

[0030] Figure 1D illustrates the use of computers of 
the type shown in Figures 1 A and 1B in a network en- 
vironment. Such computers can be used as user com- 
puters (100, 100') or as servers (192, 193), sometimes 
with nominal differences of configuration. A user com- 
puter may connect to the network 190 either directly 
(1 00') or via a network service provider, such as an in- 
ternet service provider 180. Program and data informa- 
tion used in carrying out the invention can be transmitted 
as a carrier wave over the network(s). 
[0031] Figure 2 is a flow chart of an exemplary pre- 
paid content hyperlink process in accordance with one 
embodiment of the invention. When a user requests a 
document that contains one or more links to content for 
which payment is required (200), the document is gen- 
erated (210) by the source server 192. The document 
can be generated by using a Java servelet or a common 
gateway interface (CGI) program. In any event, it is gen- 
erated anew for each access. An exemplary document 
generation process is described in detail in conjunction 
with Figure 3. Once the source document has been 
generated it is transmitted and displayed to the user 
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220. While viewing the source document the user may 
decide to click on a link to remote content 230. Remote 
content is, for example, any content that is not controlled 
by the sponsor of the page or document being ac- 
cessed. For example, a link to an additional document 
that is part of the current site would not normally be con- 
sidered a link to remote content. 
[0032] If the user clicks on a link to remote content the 
access that is not pre-paid (regular link) then access to 
that content is handled using standard techniques 
known in the art 240. If the user decides to click on a 
link to content for which a payment is required (payment- 
required content) then the address of the content (reg- 
ular hypertext link), typically the universal resource lo- 
cator (URL) or the address, and payment parameters 
associated with that link (if the link is a pre-paid link) are 
transmitted 250 to the appropriate destination server 
193. When the destination server 193 receives the URL 
and added parameters, it processes the request for con- 
tent 260 and collects the payment, by, for example, stor- 
ing digital cash or debiting the sponsor's account. The 
processing of requested content is discussed in detail 
in conjunction with Figure 5. 

[0033] Figure 3 is an exemplary flow chart that de- 
scribes an exemplary the process used to generate a 
source document in accordance with one embodiment 
of the invention. In this example a template for a source 
document is searched for links to payment-required 
content 300 to which the document author or sponsor 
desires to provide free access. When one is found the 
program adds payment information to the link as a pa- 
rameter 310, thus making it a pre-paid link. 
[0034] In a preferred embodiment using HTML, a pre- 
paid link would have the format 900 detailed in Figure 
9. The site identifier would be followed by a specification 
of the desired page followed by a marker, such as a 
question mark, 910 which indicates that parameter val- 
ues follow. The parameter values constitute exemplary 
payment information. A first parameter in this example 
is a billing account identifier 920. Next a payment token 
is generated by the source server 320. The token gen- 
eration process is discussed in detail in conjunction with 
Figure 4. The payment token is then added to the pre- 
paid link 330. In the preferred HTML embodiment the 
token is added to the billing account identifier 920 and 
is separated from it by a plus sign 930. The process then 
repeats until the end of the document file has been 
reached. 

[0035] Figure 4 is a flow chart of an exemplary proc- 
ess for generating payment tokens in accordance with 
one embodiment of the invention. The exemplary pay- 
ment token (e.g. Figure 10) is generated by adding a 
billing account identifier (1 01 0) for an author or sponsor 
of a document on the server to an empty token 400. The 
size, in characters, of the billing account identifier is 
preferably known to both the source and destination 
processes. In a preferred embodiment the billing ac- 
count identifier would be left padded with zeros, if nec- 



essary, in order to satisfy a fixed size requirement. The 
token counter is incremented by one and the new token 
counter value (1020) is concatenated to the billing ac- 
count identifier. See step 410. The token counter size is 
5 also preferably known to both the source and destina- 
tion processes. In a preferred embodiment the token 
counter should be left padded with zeros, if necessary, 
to fulfill the size requirement. The token counter is a soft- 
ware counter or a hardware counter on the source serv- 
10 er, which ensures that all tokens generated have a 
unique value. The token expiration data and time is cal- 
culated and this value (1 030) is concatenated to the oth- 
er components of the token (420). The length of time a 
token will remain valid may be previously agreed upon 
15 by the source and destination owners. The expiration 
date and time may be preferably calculated as the 
number of seconds after midnight from a predetermined 
date (i.e., January 1 , 1 997). The token number (see Fig- 
ure 10) may be large, in which case it is then converted 
20 into a base 36 number in order to compress it (430). 
Base 36 numbers make use of the digits 0-9 and the 
letters A-2. The base 36 number is preferably encrypted 
using the current site's private key 440. 
[0036] Public-key/private-key cryptography is a 
25 known technique for providing security when transmit- 
ting data over a communication s network. Public-private 
key cryptography is based on a mathematical process 
that generates two keys where one key cannot be de- 
termined from the other. In use, the private key is known 
30 only to the user. Typically it is a long series of characters 
stored on the user's computer. The public key is "pub- 
lished", i.e. it is made available to anyone who wants it. 
When a user needs to send a secure transmission, the 
data is encrypted using one of the private or public keys. 
35 When the transmission is received the recipient can de- 
crypt the data using the other of the private or public key. 
The originating site would typically encrypt with its pri- 
vate key and the pre-paid content provider would de- 
crypt using the originating site's public key. 
40 [0037] Figure 5 is a flow chart of an exemplary des- 
tination server process for handling requests for content 
in accordance with an exemplary embodiment of the in- 
vention. The destination server (193) first determines if 
the requested content requires a payment 500. This can 
45 be done by querying a database of payment-required 
URLs on the destination server. If the requested content 
does not require a payment then the destination server 
transmits the content to the user 510. If the content re- 
quires payment to view or download it and the request 
so has arrived from a pre-paid link, then the destination 
server parses the source site's billing account identifier 
and the payment token from the end of the URL (see 
Figure 9). This parse procedure can be done easily by 
looking for the characters between the question mark 
55 (910) and the plus sign (930) The destination server us- 
es the source site's billing account identifier to find the 
source site's public key in a database 530. The destina- 
tion server uses the public key to decrypt the token 540. 
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The token is then converted back into a base 1 0 number 
and the source site's billing account identifier, the token 
expiration data and time, and the token counter value 
are parsed out 550. The parse procedure can be accom- 
plished because the size of the customer identifier and 
token counter are known. The destination server then 
attempts to validate the token 560. The token validation 
process is discussed in detail in conjunction with Figure 
6. 

[0038] Figure 6 is a flow chart of an exemplary token 
validation process in accordance with one embodiment 
of the invention. The token validation process, which 
runs on the destination (pre-paid content provider) serv- 
er (193), first attempts to match the source site's billing 
account identifier included in the parameter (920) with 
the source site's billing account identifier included in the 
token (1010) 600. If the two numbers do not match, an 
error message stating the token cannot be recognized 
will be displayed to the user 610. Any error message 
given to the user will result in an option to return to the 
source document to try the link again or to pay for the 
content themselves 690. If the billing account identifiers 
match, then the token validation program will check the 
expiration date and time against the current system date 
and time 620. If the token has expired then a token has 
expired error message will be displayed to the user 630. 
If the token has not expired then the token validation 
program will attempt to find the token counter in its da- 
tabase of previously honored tokens 640. If the token 
counter is found in the database then a message stating 
that the token has already been used will be displayed 
to the user 650. If the token counter is not found in the 
database then the token validation program will check 
to see if the source site has sufficient credit to pay for 
the transaction 660. Since payment may take many 
forms the token validation program will first determine 
the payment type by accessing the customer's account 
information in the database. If, for example, the custom- 
er makes pre-payments then the validation program will 
determine if enough money remains in the account to 
pay for the transaction. In other cases the customer may 
have established credit, in which case the validation pro- 
gram may need to check the customer's credit limit. If 
the customer is not able to pay for the transaction then 
a message stating that pre-payments from the source 
site are currently not being honored, will be displayed to 
the user 670. If the customer has the ability to pay for 
the transaction then the token is honored 680. The token 
honored process is discussed in detail in conjunction 
with Figure 7. 

[0039] Figure 7 is a flow chart of an exemplary proc- 
ess of a destination server honoring a valid token in ac- 
cordance with one embodiment of the invention. When 
a token is honored the requested content is transmitted 
and displayed to the user 700. In addition, the source 
site is billed in accordance with the payment arrange- 
ments made between the source and destination sites 
710. If, for example, the source site has established a 



pre-paid account with the destination site then the pay- 
ment for the transaction is subtracted from the amount 
of money in the pre-paid account. If, on the other hand, 
the destination site bills the source site on some regular 

5 basis then the number of transactions in the source 
site's account will be incremented by one. In addition to 
billing, the token counter and expiration time and date 
are stored in an honored tokens database 720 indexed, 
for example, by sponsor. As before, time is preferably 

10 stored as a number of seconds after midnight on a ref- 
erence date. This database is used in the validation 
process 640. 

[0040] Figure 8 is a flow chart of an exemplary main- 
tenance process for the honored tokens database. 

is Since tokens should only be kept in the honored tokens 
database until their expiration time a maintenance pro- 
gram will need to be run on the database at a regular 
interval (i.e. , every hour). First, the current time and date 
are determined from the system clock 800. Next, the da- 

20 tabase is queried for tokens that have expired based on 
the current time 810. Finally, expired tokens are deleted 
from the database 820. 

[0041] Although the present invention has been de- 
scribed and illustrated in detail, it is clearly understood 
25 that the same is by way of illustration and example only 
and is not to be taken by way of limitation, the spirit and 
scope of the present invention being limited only by the 
terms of the appended claims and their equivalents. 



Claims 

1. Apparatus for permitting access to services for 
which a payment is required, comprising: 

a. a network port; and 

b. a computer, connected to said network port, 
configured to generate a document having a 
link to services on a network for which an ac- 
cess payment is required and to associate pay- 
ment information with said link by which access 
to said services may be obtained without pay- 
ment by a user following said link. 

2. Apparatus of claim 1 in which said document is gen- 
erated using one of a Java servelet and a common 
gateway interface program. 

3. Apparatus of claim 1 in which said payment infor- 
mation includes one or more of a billing account 
identifier and a payment token. 

4. Apparatus of claim 3 in which said token comprises 
one or more of a token number, an expiration date 
and expiration time. 

5. Apparatus of claim 3 in which at least part of said 
payment information is encrypted. 
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6. Apparatus of claim 1 in which said services includes 
providing information. 

7. Apparatus for permitting access to services for 
which a payment is required, comprising: 

a. a network port; and 

b. a computer, connected to said network port, 
configured to provide access to services under 
control of said computer upon receipt of pay- 
ment therefore and to extract payment informa- 
tion from a connect received over said network 
port. 

8. Apparatus of claim 7 in which said computer man- 
ages a database. . 

9. Apparatus of claim 8 in which said database con- 
tains account information about one or more cus- 
tomers authorized to provide pre-payment. 

10. Apparatus of claim 9 in which said database con- 
tains information about tokens which have been 
honored. 

1 1 . Apparatus of claim 7 in which said computer is con- 
figured to check whether said payment information 
is valid. 

12. A method of pre-paying for services accessed over 
a computer, comprising the steps of: 

a. providing an element for performing the step 
of generating a document containing a link to a 
service provider; and 

b. providing an element for performing the step 
of associating payment information with said 
link. 

13. The method of claim 12 in which said service pro- 
vider provides information for a fee. 

14. A method of providing a service for a fee, compris- 
ing the steps of: 

a. receiving an connect request containing pay- 
ment information over a network; and 

b. providing the service once said payment in- 
formation is determined to be valid. 

15. A system for providing a service for a fee, compris- 
ing: 

a. a network; 

b. at least one computer connected to said net- 
work and configured to generate a connect re- 
quest containing payment information; and 

c. at least one server connected to said network 



configured to extract payment information re- 
ceived with a connect request and to provide a 
service when said payment information is de- 
termined to be valid. 

16. The system of claim 15 in which said service in- 
cludes providing information. 



17. A computer program product, comprising: 

10 

a memory medium; and 
a computer program stored on said memory 
medium, said program comprising instructions 
for generating a document containing a link to 
'5 a network address and associating payment in- 

formation with said link. 

18. A computer program product, comprising: 

20 a memory medium; and 

a computer program stored on said memory 
medium, said program-comprising instructions 
for receiving an connect request containing 
payment information over a network and pro- 

25 viding a service opce said payment information 

is determined to be valid. 

19. A computer controlling product, comprising: 

30 a memory medium; and 

a document stored on said memory medium, 
said document containing a link for connecting 
to a remote computer said link containing pay- 
ment information. 

35 

20. A computer controlling product, comprising: 

a memory medium; and 
a document template stored on said memory 
40 medium, said document template containing a 

slot for identifying information for connecting to 
a remote computer and payment information. 
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